This invention relates to communication networks. More precisely, it concerns the problem of transmission of signal messages through address translation equipment such as ((NATs)).
Existing communication networks can be used to set up a communication session through signal protocols such as H.323, MGCP (Media Gateway Control Protocol) or SIP (Session Initiation Protocol) and SDP (Session Description Protocol).
This SIP protocol is defined by the IETF (Internet Engineering Task Force) RFC 3261 and it has two purposes, namely:                to bring two parties into contact,        to negotiate characteristics of the session to be set up (video flow, CODEC encoder to be used, etc.), through the SDP protocol.        
A calling party who would like to call another party can send an (((Invite))) signal message to a signal element called a ((Proxy)), containing its personal address, the physical address of its terminal (or more generally a client) and the personal address of the called party. The signal element has (((registrar))) means to make the personal address of the called party correspond to the physical address of the corresponding terminal. Due to this correspondence, the signal message may be routed to the calling party.
If the calling party accepts the call, the calling party replies with new signal messages comprising the physical address of the terminal or client. Thus, when each of the two terminals knows the physical address of the other party, they can set up on IP (Internet Protocol) connection for transmission of data (voice, video, etc).
However, a problem sometimes arises with network address translation (NAT) or Network Address-Port Translation (RAPT) equipment as defined in RFC 1631. ((The IP Network Address Translator)), and in RFC 3022 Traditional IP Network Address Translator (Traditional NAT))). This equipment is designed to interface a sub-network (typically a private network) with the Internet public network. The validity of the physical IP addresses of the equipment (terminals) in this sub-network is *limited to the sub-network. When this equipment wants to set up communications with equipment outside the sub-network, the address translation equipment assigns a temporary public address to it that is valid for the public network and memorizes the association between the client's private address and its temporary public address.
Therefore, the network address translation (PAT) equipment modifies messages transmitted between the private network and the public network during this transmission, by                transforming terminal private addresses into public addresses in IP headers of outgoing messages, in other words from the private network to the public network, and        transforming public addresses of terminals into private addresses in the IP headers of incoming messages, in other words messages from the public network to the private network.Therefore, a problem arises for the address translation traversal equipment by SIP/SDP (or H.323 or other) signal messages. This problem is known under the term ((NAT traversal)).        
For example, it is described in the IETF RFC 3235, entitled ((Network Address: Translation (NAT)—Friendly Application Design Guidelines)).
Signal protocols such as SIP and SDP are considered—as application protocols. For example, the SIP/SDP protocol may be transmitted by the TCP or UDP protocol, themselves located higher than 1P in the protocol stack. Therefore, a SIP message is actually a sequence of parameters encapsulated in a TCP or UDP message, itself encapsulated in an IP message.
Network address translation (NAT) equipment only modifies parameters at the level of the IP layer, and leave parameters located in higher layers intact. In other words, physical addresses contained in SIP and SDP messages are not modified by address translation equipment, unlike addresses contained in the IP headers.
The result is that the addressee (called client) of the signal message will only know the private address of the calling client. But the private address is meaningful only in a private network, and therefore, a communication session cannot be set up.
Since this problem is well known, a large number of solutions have been proposed to solve it. Two main approaches can be’ distinguished to solve this problem: approaches based on the calling client and approaches based on a server or communication network equipment.
The first category includes the STUN (((Simple Traversal of UDP through NATs))) mechanism described in RFC 3489. This mechanism enables a client (or terminal) to know its public address. Thus, prior to emission of a message to the public network, the calling client transmits a request to a STUN server located* in this public network. This STUN server will reply with a message containing the address (and the port) at which it sees D the client, in other words its public address.
The client can then use this public address to indicate the address at which it wants to receive the responses, through the SDP protocol.
However, this solution suffers from a major limitation because many NATs are said to be ((symmetrical)) and associate a public address with a pair of parties. The public address that the NAT assigns to the client may thus be different for communication with the STUN server and for the session to be set up with the other party. In this case, it is impossible to set up a communication between the client and the other party.
Other proposals to ‘improve the situation have been made based on the same principle, such as TURN (((Traversal Using Relay NAT))) mechanisms. The TURN mechanism is described in the ((draft-roseenberg-midcom-turn-09.txt)) document published on the IETF site in March 2006.
However, neither the STUN mechanism nor the TURN mechanism is adapted to the SIP protocol.
A new mechanism, ICE (<<Interactive Connectivity Establishment>>) has thus been proposed to adapt the transit of SIP signal messages. It is based on STUN and TURN mechanisms, while adapting them. The ICE mechanism is described in the ((draft-ietf-30 mmusic-ice-09.txt)) document, also published on the IETF site in June 2006 and entitled cc Interactive Connectivity Establishment. A Methodology for Network Address Translator (NAT) Traversal for Multimedia Session Establishment Protocols)).
The second category of solutions is based on equipment within the communication network. Note that the first solutions used a server within the network (for-example a STUN server), but the initiative was with the client. On the contrary, in this second family of solutions, the network equipment takes the initiative and implements NAT traversal solutions.
A first solution belonging to this family may for example be to associate an. application gateway with the network translation equipment NAT. This mechanism is known under the name ALG for ((Application Layer Gateway)) or ((Application-level Gateway)) and is defined in section 2.9 in RFC 2663 entitled ((IP Network Address Translator (NAT) Terminology and Considerations)) published in August 1999.
This gateway (or a NAT with the functions of such a gateway) has means of understanding application protocols used by messages. In particular, it can understand the content of signal messages and translate physical addresses contained in SDP messages so that the parties exchange their public addresses and not their private addresses, and can thus set up communication sessions.
One variant of this solution consists of using a so-called SBC (<<Session Border Controller))) that will be located on signal message paths. This type of product is capable of controlling the transmission of communication sessions and signal messages between the two networks. More precisely, the SBC can act as a SIP signaling “proxy”, that provides means of controlling media transmission means (a ((media proxy))) through a protocol such as Megaco so that communication sessions can be suitably set up between the parties.
Other solutions are still available in each of these two major categories, although none has definitively taken the lead over the others.
Thus, a particular communication network can implement several solutions simultaneously. A communication client does not know a priori if the network with which he is. associated uses a traversal solution: it can then implement an ICE type solution while the network uses an ALG or SBC type solution.
The fact that two solutions are deployed is redundant and causes loss of resources, but solutions can also mutually disturb each other and cause incorrect operation of the communication network; the ALG or SBC equipment may modify addresses contained in SIP/SDP signal messages incorrectly or when they should not have been modified. Finally, communication sessions cannot be set up.
Apparently this problem has not yet been raised.
One solution that could be proposed would be to deactivate mechanisms used by a SIP client (ICE, STUN, TURN . . . ) manually when this client knows that it is ((attached)) to an SBC or an ALG gateway.
However, such a method would be complex to implement; a client cannot know that it is attached to an ALG gateway or to an SBC unless it knows the topology of its access supplier's network. Furthermore, the configuration must be modified manually every time that the client is attached to a new network.
Furthermore, this approach is not optimum because as soon as a solution based on an ALG gateway or an SBC is deployed, by construction it is preferred to the solution based on the client. But the client-based solution is usually optimum. because the client can use it to control setting up the communication session and this solution does not use a media relay like SBC or ALG solutions.